Claude finished @AndyButland's task in 4m 10s —— View job

PR Review

Target: origin/v17/dev · Based on commit: 8e7c070b

Fixes a browser-specific edge case where <input type="date"> (and time/datetime-local) briefly reports value === '' during segment editing (e.g. typing 0 into the month field before the second digit). The prior code reflected that empty value back via Lit's reactive binding, clearing all filled segments. The fix overrides onInput to skip the empty reflection and uses a focusout listener to commit an intentional clear when focus leaves.

• Other changes: Date inputs no longer clear while the user is mid-keystroke in a locale-formatted segment (e.g. dd.MM.yyyy in German). An intentional full clear is still committed on tab-out/blur.

Suggestions

• input-date.element.ts:61 — UUIInputEvent.INPUT is dispatched unconditionally, even when target.value === '' and this.value was not updated. A consumer reading element.value inside their input handler will see the unchanged (stale) value — which produces correct downstream behaviour — but the event fires without any value change, which is semantically odd. Guarding the dispatch with the same condition would be cleaner (see inline comment). Fix this →

• input-date.element.ts:37-44 — The focusout handler dispatches both INPUT and CHANGE when this.value !== native.value. If UUIInputElement also emits UUIInputEvent.CHANGE when it processes the native change event at blur (which fires before focusout), an intentional clear would produce two CHANGE events — the first with the stale value, the second with ''. Worth verifying against UUI source. If double-dispatch is confirmed, the native change listener in the parent could be suppressed or this handler could guard against it (e.g. by checking whether the native change event already propagated the correct empty value).

• input-date.test.ts — Tests cover type="date" only. Since the element also supports type="time" and type="datetime-local", and transient-empty behaviour is consistent across these types, a brief note in the test file (or an additional test case) would make the intent more explicit to future maintainers.

Approved with Suggestions for improvement

Good to go — the core fix is correct, well-reasoned, and the three test cases cover the key scenarios described in the PR. The suggestions above are minor and don't block merging.

Labels applied: area/frontend, category/ux, category/ui

Tested this out, it works when entering a zero 0 for the day and/or month parts, but not the year part. e.g. if I try to replace 2026 with 2025, the value will empty after I input 20.

Interesting. That's what the original report is about on the issue, but I couldn't seem to replicate that. I could type "2026" fine without anything tripping up on the "0". I would only see the issue typing a "0" for the month. Maybe there's a browser/operating system difference?

I'm on Windows 11 / Chrome (148). Just tried with Firefox (151) and it all works as expected.

Also using Windows 11/Chrome - so actually that doesn't really explain it. I'll check again... no, seems I don't see it. Weird.